GUIDO - Open Data Process Guide
During my time as a Design Fellow with Tech4Germany our team worked on the project "Open Data Portal" in cooperation with GovData and the Ministry of Foreign Affairs. GovData is the German Open Data Portal. The aim of the project is to make the portal more user-friendly for data providers and data consumer. You can find out more about the project on it's website:
Type
Web Application / Sharepoint Web Part
Team
We were a team of four - one product fellow, two design fellows and one engineering fellow
My role
• creating low and high fidelity wireframes
• creation of user flows
• analysis of user and stakeholder needs
• concepting and prototyping
• facilitating design thing workshop
• conducting expert and user interviews and writing interview guidelines
• creation of user flows
• analysis of user and stakeholder needs
• concepting and prototyping
• facilitating design thing workshop
• conducting expert and user interviews and writing interview guidelines
• evaluating user interviews and write reporting
• UX writing
• supporting the engineering fellow with CSS styling and implementing the header
Design process
1.) Discover - Gather insights and information by doing expert interviews
2.) Define - Cluster and discuss findings and define problems
3.) Ideate - Brainstorming and prioritization of ideas
4.) Prototype - Develope a prototype and build a click dummy
4.) Test - User interviews and testing and implementation of findings
5.) Deliver - Wrap up and handover
Discover
Since there was no fixed project scope in the beginning, we were starting by talking with a lot of people (open data experts, people who work in or with the public sector, data journalists,...) to scope the problem. As a first step we tried to cluster our findings in four categories: Problems, Opportunities, Surprises / Insights and Questions. Additionally we had a "out of scope" category which served as a place for findings we couldn't solve but wanted to include in the documentation.
First attempt of sorting our findings. A more neatly arranged cluster was later set up at our miro board.
After several rounds of clustering and refining we came up with a structure which helped us to make the problems we found more comparable by putting them into context and create a kind of hierarchy. This helped us to find the right level for the problems we wanted to work with (orange colored post its in the picture below). Overall we were able to define 6 problems this way, which were prioritized with our stakeholders.
Structure to cluster and compare problems which was named "Problemkrake" internally.
Personas
After finding there main problem statements we once again looked at the research we found during user and expert interviews as well as desktop research (studies and best practises done by other countries). We used several methods to evaluate our research and make it more useful in order to help us to decide which problem we should tackle during the 12 weeks. One method we used were Personas which helped us to get a better understanding for the different user groups.
An example of the Personas we came up with (9 in total).
Define
With the insights we gathered during the discover phase, we continued to go deeper into the problems we came across. As a first step we added a point of view (POV) to each persona we created during the discover phase.
Based on those POVs we created "How might we..." questions which were the foundation for the following brainstorming.
How might we..." questions and brainstorming.
Ideate
Based on the ideas we came up with during the brainstorming, we selected the ideas, which seemed to be the most doable / realistic to us and tried to define them a bit more by creating an idea canvas for each of them. With those canvasses we organized a workshop with our project partners to get their opinion on our ideas, gather additional feedback and prioritize once again. Additionally we created a matrix for scoring the ideas by impact, added value, innovation, risk and effort to get a better feeling for the ideas we want to focus on.
Idea canvas for Open Data Project Guide.
First scribbles
By using the scoring method mentioned above, we focussed on two ideas. As a first step in the wireframing process each team member started to draw scribbles for those ideas on paper within a predefined timeframe. The previously selected idea canvas were used as the basis for this. There were no guidelines, whether these were procedures or already first scribbles for screens. The results were compared and discussed afterwards.
First scribbles.
User Flow
After realizing that there is no pre existing process for uploading open data within the ministery of foreign affairs we decided that to create a structure for that based on a user flow would be helpful. We also referenced the Prozessbeschreibung zur Veröffentlichung von Daten provided by CCOD which helped a lot to understand all the steps involved in the process.
Parts of the early user flow.
Prototype
Based on these initial ideas, the design team started to build the first low-fidelity screens and gradually converted them into a low-fidelity prototype. From the scribbles it became clear that this should represent two core steps: the process modeling process and the process of data provision and verification.
First screens of the low fidelity prototype.
Based on those low fidelity wireframes we got a good idea how the product could work. Since we wanted to test our assumptions as quick as possible, we needed to build a click dummy for the purpose of user testing and decided to use Google's Material UI for the first high fidelity prototype.
High fidelity prototype before usertesting.
Test
To prepare the user testing I wrote an interview guideline with several general questions and some more particular questions to test the hypothesis we wanted to validate. Overall we talked to 5 people who work in the ministry of foreign affairs. One additional person also tested the final prototype at a later time. As part of the user testing we also asked every participant to fill out a short survey to determine the SUS score of our prototype. With 5 participants the prototype reached a SUS score of 83, which is a good result. The key findings of the user testing were incorporated in the next iteration of the prototype. We also came across some logical issues which needed to be fixed as well.
Since it didn't seem realistic to us to create our own design system due to the shortage of time, we chose Microsoft's Fluent Design. This choice was made for two main reasons. Firstly, it was already clear at that time that the tool would be located in a Microsoft sharepoint and we wanted it to fit in there consistently. Secondly, we wanted to orient ourselves to the habits of the administrative staff, for whom Microsoft products and solutions are part of their everyday work.
Final Version of the design.
Deliver
Since the project's timeframe was only 12 weeks we had to make some sacrifices when it came to features and functionalities we had in mind. In the end we decided that we will build a MVP version of the product and handover all other ideas together with all findings we gathered during our research in an extensive documentation.
Summary
What we archived in 12 weeks was an in-depth analysis of the current status quo which we handed over in a detailed documentation describing our process and all our findings. On the coding side we archived to create a MVP version of the product we envisioned which can be integrated in Microsoft sharepoint.
What I've learned
• Going through all project phases and building a prototype in a very short amount of time
• Navigating the public sector
• Microsoft Fluent Design
• UX writing
• Intro to UX writing
